Today I finished my master’s thesis. Hooray. The title is “ContextR & ContextWiki – Modularisierung von Webanwendungen mit kontextorientierter Programmierung” or “Modularization of Web Applications Using Context-oriented Programming”. An abstract will be available, after it was graded. The full version will be public as well, although I’m not sure when.
In the mean time, you might be happy with the code. ContextR and ContextWiki are available at github.
I will happily attend the Euruko 2008 in Prague. Hope to see you there.
I'm using www.bibsonomy.org to manage my bibtex entries. This is a must have, when writing any scientific paper. Bibsonomy is like del.icio.us just for bibtex. Among the social and webscraping features to collect bibliography entries it has a bibtex export to create .bib-files for your local latex project.
The problem, we will solve today: Fetch the bibtex export from bibsonomy.
wget http://www.bibsonomy.org/bib/user/schmidtwisser?items=1000 -O literatur.bib
This solution is simple and was useful for a long time. Unfortunately I recently added private bib-entries. Since this solution doesn't use any authentication, it only delivers my public entries.
So I needed to either use bibsonomy's API, which would need registration, or I need to authenticate, keep the cookie and then fetch my bibliography. Enter mechanize:
require "rubygems"
require "active_support"
require "mechanize"
config = YAML::load_file(File.join(ENV['HOME'],
".bibsonomy.yml")).symbolize_keys
agent = WWW::Mechanize.new
page = agent.get('http://www.bibsonomy.org/')
form = page.forms.action('/login_process').first
form.userName = config[:username]
form.loginPassword = config[:password]
page = agent.submit(form)
page = agent.get("/bib/user/#{config[:username]}?items=1000")
File.open("literatur.bib", "w") do |f|
f.puts page.body
end
It is so easy, I won't even explain the code.
Just one bit: Don't embed your password in any public code, so do I. My credentials are therefore stored in my Home-directory.
Today a simple question arose. How to use alias_method_chain for class methods a.k.a. singleton methods a.k.a. instance specific methods for class. I just tried to answer the question, but finally I recognized, that it was't actually necessary to use alias_method_chain at all. The aim was to add behavior to validates_presence_of, an ActiveRecord method, that installs a check to ensure, that a certain value is set, before data is send to the database.
So let's have a look at the prerequisites first. I'll translate the actual implementation into an easier example. ActiveRecord will most likely implement class methods in a module, that is mixed into the singleton class of all subclasses. This looks a lot like the following code, where ActiveRecord::Base becomes Base and validates_presence_of becomes class_method.
class Base
module ClassMethods
def class_method
"base implementation used"
end
end
def self.inherited(sub)
sub.extend ClassMethods
end
end
Whenever this class is subclassed, the inherited method will be called an the class methods added as described. If you want to add more specific behavior to the class_method you got multiple options. But there is no need to use method aliasing with ActiveSupport's alias_method_chain. Modules, even the ones extending Objects have an inheritance relation. So let's use super powers.
Define your own ExtendedBase that you may mix in to your classes, that need the additional behavior.
module ExtendedBase
module ClassMethods
def class_method
"extended and " + super
end
end
def self.included(sub)
sub.extend ClassMethods
end
end
This code uses the same ClassMethods technique as the class above, but the call back is called inherited this time. It provides a special implementation for class_method and delegates to the next one in the inheritance chain for the more general stuff.
It is used like the following:
class A < Base
include ExtendedBase
end
If no reuse is necessary, you may savely add the behavior to the single class, where you need it. Just open up the metaclass a.k.a. eigenclass a.k.a. singleton class and define your methods. Again, you may simply delegate to the base implementation using super.
class A < Base
def self.class_method
"custom and " + super
end
end
Hehe. The description was more verbose than the code, but trust me it was still correct.
To make clear, that everything works as expected, I will add a test. I assume, that all the above definitions are loaded.
require "rubygems"
require "dust"
unit_tests do
test "should call all three implementations" do
assert_equal("custom and extended and base implementation used",
A.class_method)
end
end
You should always have a look at your tools and know how your inheritance hierarchy looks like. It can things so much easier. Ruby's method lookup follows a simple rule.
It is always possible to jump from one implementation to the other with the use of super. And if you are not sure, which implementation will be used first, ask your ancestors.
In this case a super call is much more expressive than the use of method aliasing. It does not pollute your objects instance methods list and it will never produce name clashes.
When trying to remove behavior from your classes or objects, you will quickly stumble upon undef_method and remove_method. Even when your are just trying to change an implementation you will need one of these. Otherwise Ruby will warn you, that you are discarding an older code chunk.
So let's quickly examine the basic difference between the two. The RDoc of undef_method already gives good starting point.
Prevents the current class from responding to calls to the named method. Contrast this with remove_method, which deletes the method from the particular class; Ruby will still search superclasses and mixed-in modules for a possible receiver.
There is also some sample code, but mine will be better. (No, it will not, but have you ever heard of NIH?) And I will use two test techniques promoted by Jay Fields to make sure, your mind is still able to move a bit. These are dust and anonymous classes for tests. Not too much magic for the rest of us, but both make posting test code a lot easier, quicker and more readable.
I will post it in chunks. At the end of the article you will have a complete ruby test.
require "rubygems"
require "dust"
No magic. Just wait a bit more...
unit_tests do
This is dust's way to say class FooTest < Test::Unit::TestCase. I really like dust.
def setup
@base_class = Class.new do
def method
"answered in base class"
end
end
@sub_class = Class.new(@base_class) do
def method
"answered in sub class"
end
end
@base_instance = @base_class.new
@sub_instance = @sub_class.new
end
The setup method is pretty basic. We are creating a fresh inheritance hierarchy for every test method. This will simply prevent undesired side effects. Changes to classes are so global. Okay, the @base_class -- actually it has no name, but anyways -- has a single method method. @sub_class inherits from @base_class -- now I get the naming schema -- and defines its own version of the method method.
For each run, I also instantiate an instance for each class to play with.
test "Basic setup works" do
assert_equal @base_instance.method, "answered in base class"
assert_equal @sub_instance.method, "answered in sub class"
end
This is dust's way to say def test_basic_setup_works; ...; end. How do you fell?
The code itself is really basic. I'm just making sure, that the setup works and nobody changed my tests significantly.
remove_methodLet's start with the well-behaving twin: remove_method.
test "remove_method let's you undo method definitions" do
@sub_class.send(:remove_method, :method)
assert_equal @base_instance.method, "answered in base class"
assert_equal @sub_instance.method, "answered in base class"
end
I'm using send here to circumvent the visibility restrictions. Don't do this at home. Use class_eval instead. Your children (using 1.9) will be happier.
After removing a method, its definition is removed from the class itself. When you try to access it, the correct implementation will be searched within the ancestors. This way you can get rid of your customizations and activate a more general definition. This is mainly the thing you would want to use, before redefining a method, to get rid of the warning.
There is not much else to say about it. Sorry.
undef_methodThe less it sounds like plain english, the hackier it is (ref. awk vs. grep). undef_method does not only remove the definition from the current class, but causes Exceptions. Let's have a look at the tests first.
test "undef_method causes NoMethodErrors" do
@sub_class.send(:undef_method, :method)
assert_raise(NoMethodError) { @sub_instance.method }
end
Although, there is a definition in the base class, it is not used. Instead, we get an error. Okay, but this might make you think, that now, the method method is totally gone ...
test "undef_method does not affect superclasses" do
@sub_class.send(:undef_method, :method)
assert_equal @base_instance.method, "answered in base class"
end
... no it is not. It is still there -- in the base class. undef_method actually hides all implementations in superclasses. This somehow breaks the inheritance relation. Although sub inherits from base and although base has an implementation and sub does not, the happy programmer caused a NoMethodError. The following test shall stress this reasoning.
test "undef_method breaks inheritance" do
@sub_class.send(:undef_method, :method)
assert @base_class.instance_methods.include?("method")
assert @sub_instance.kind_of?(@base_class)
# This is the point where you should say: No!
assert !@sub_instance.respond_to?(:method)
end
We are still missing an
end
here. The test is done, it will work on all 1.8 compatible machines.
More or less -- without the hooks to update the functionality of respond_to, instance_methods and their friends -- remove_method and undef_method could be implemented like the following
class Module
def remove_method(name)
define_method(name) do
super
end
end
def undef_method(name)
define_method(name) do
raise NoMethodError,
"undefined method `#{name}' for #{self}",
caller(1)
end
end
end
The one passes control flow to an implementation somewhere else, the other raises Exceptions. Try it, think about it, and tell me, why one needs undef_method.
Since we are all social guys, telling everybody what we are doing right now, as often and as detailed as possible, it is just right, to do this automatically. So for everybody living on the command line and in Ruby the following quick snippets might be useful.
As you might know, I'm currently writing my master's thesis -- in LaTeX. And there is a quick command to calculate the current word count.
detex mainfile.tex | wc -w
detex strips all the LaTeX commands out of your document, but it follows includes, so all you got in the end is a plain text version on STDOUT. wc is one of this great old unix tools, it simply counts lines, words and characters. The -w options limits the output to a single number -- the number of words.
This will be the first building block.
The first target of social striptease will be Skype. At least in my contact list, it is usual to let everybody know what you are listening to, where you are and what you are doing, with the help of mood messages. Sometimes they are even used for chatting. To set a mood message from the command line is pretty easy. I will be using the rb-appscript gem which allows to execute AppleScript from Ruby. Consequently this works only on a Mac.
require 'rubygems'
require 'appscript'
include Appscript
app("Skype").send_ :script_name => "Raketask",
:command => "SET PROFILE MOOD_TEXT I'm in Ruby mood"
The necessary information for this snippet were taken from the rb-skypemac gem (the way to talk to Skype via rb-appscript) and from this blog post (german) of a friend of mine (the way to set a mood message via AppleScript).
Wouldn't it be great if all my friends get an SMS, when I wrote five words, yes it would. So let's build a simple Twitter integration. There is the great twitter gem which let's you forget all the API nastiness and gives you really simple access from Ruby and your plain old command line. If you set up your Twitter credentials in ~/.twitter the command line tool automatically picks them to authenticate. I will use them to minimize the setup costs. Unfortunately, the Ruby API has no official way to access the config file in your home directory. But this is not a reason to stop. I'm using the send method here to circumvent visibility restrictions.
require "rubygems"
require "twitter"
require "twitter/command"
config = Twitter::Command.send(:create_or_find_config)
Twitter::Base.new(config['email'], config['password']).post("Ruby? Anybody?")
I have a Rakefile to compile my thesis using latex. In there are options to do a quick compile for preview and a longer compile including images for a final version. I have a task to open the generated PDF in Preview (using AppleScript again) or to fetch my bibtex file from bibsonomy.org. So why not add tasks to count words and to post the current status to Skype and Twitter. Now we have everything in place. So without and further ado, here is a snippet from my Rakefile:
desc "Counts words of main document"
task :count do
puts "#{`detex #{PROJECT_NAME} | wc -w`.strip} words in thesis"
if (file = ENV["file"])
puts "#{`detex #{file} | wc -w`.strip} words in #{file}"
end
end
This is the main count task. It simply prints the current word count to the command line. Additionally it is possible to count the words in a single file by passing in a file parameter (rake count file=chapter_1.tex).
namespace :count do
def count
count = `detex #{PROJECT_NAME} | wc -w`.strip
"Current word count in master's thesis: #{count}"
end
desc "Post word count to Twitter"
task :twitter do
require "rubygems"
require "twitter"
require "twitter/command"
config = Twitter::Command.send(:create_or_find_config)
Twitter::Base.new(config['email'], config['password']).post(count)
end
desc "Post word count to Skype"
task :skype do
require 'rubygems'
require 'appscript'
include Appscript
app("Skype").send_ :script_name => "Raketask",
:command => "SET PROFILE MOOD_TEXT #{count}"
end
end
This code may look familiar. It is the Skype and Twitter integration. The task use a common method count to get the numbers from the command line.
This were the not so quick Rake goodies. Thanks for your attention.
After my short Announcement yesterday, I’d like to go on an name some of the highlights.
Besides the basic functionality proposed in the original article, it has some more neat features, that make the life of its users enjoyable and fun.
So you better start using structured_warnings now.
Using the block syntax to disable warnings provides a dynamic scope of deactivation. Not only everything within the block will raise no warning, but every piece of code, that is accessed from there on. This can become very powerful for certain uses.
You never know exactly, so deactivating a warning for a dynamic scope may be overridden by enabling it again in a deeper scope and the other way round.
Each warning is passed to a warner instance, which it there to format the information, which is put to stdout. This warner may be changed for –again – a dynamic scope. This way you may instruct your favourite web framework to use a specific warner, that fetches all the information and writes it to a database instead of stdout.
Perhaps you want to have warnings in your merchant library to be to you via twitter message. Who knows? It will be pretty easy. Just have a look at the warner that is used for the test assertions. It will give you a good start.
Instead of redefining the Kernel#warn method directly, structured_warnings simply defines its own warn. The module is mixed into Object, so that every warn will go to this implementation first. After collecting all the necessary information, checking if the current warning is not disabled and formatting the output, the resulting message is passed on to the base implementation.
This way it is possible to add other extensions to you warning mechanism, you may freely redirect stderr to whatever you want. structured_warnings warn will just do, what it is supposed to.
Today I finished the documentation part. Now each and every method, public or not is documented. Just have a look at the RDoc generated API site.
Come on. The main goal is to avoid the use of code, that raises warnings. With the help of this library it is as easy as it gets to do that. A warning should always be an exception (not in the sense of the Ruby class, but in the sense of “not common”), so who will be concerned about performance.
The only thing I can tell you is, that structured_warnings will slow down calls to warn but it will not slow down your whole code and that is what counts.
Read this article by Daniel Berger first.
I just implemented his suggestions and made them available via RubyGems and our rug-b Rubyforge account. Have a look at the gems website and leave me a comment, if you like.
A simple gem install structured_warnings will bring it to your machine, another require 'structured_warnings' brings it to your project and tests.
The implementation relies heavily on Christian Neukirchen's dynamic.rb.
Disclaimer: I cannot manipulate the rb_warn method, so all the "method redefined", "void context" and "parenthesis" warnings will remain active.
After some time, I continued to work on my latest Camping project. But unfortunately, I didn't work as expected. The problem is easily spotted, static files were not delivered, the dynamics were just fine.
To cut it short: The solution is simple. There is a slight incompatibility concerning the X-Sendfile header between Camping and Mongrel v 1.1.3 (ref. 1). Until the problem is solved in v 1.1.4 you shall simply stick to the older Mongrel.
In order to get Camping to use it you need to change the camping executable. I recommend using the latest version of Camping from the Subversion repository. You may download it with a simple svn co http://code.whytheluckystiff.net/svn/camping/trunk camping. The change is in bin/camping around line 88:
...
begin
gem 'mongrel', "<1.1.3"
require 'mongrel'
require 'mongrel/camping'
...
A simple rake gem and sudo gem install pkg/camping-1.8.gem will install the changes to your system.
Happy Camping, again.
I think every great product deserves merchandising articles - so shall my thesis and ContextR. Therefore I created a logo/cartoon that represents my favourite typing discipline.
If anyone is interested in it, as I am, you may create your own products in the (German) spreadshirt shop. If you are having problems feel free to leave a comment or send a mail.
Mostly off topic, but I wanted to share it anyway.
We terminal cowboys often have the same problem. I'm in my current workspace, represented by a certain directory. But I would like to open a new Terminal window pointing to exactly the same directory. Hitting [Apple]+[n]1 will open a new window, but is points to $HOME. (Sidenote: gnome-terminal knows its customers better. It opens at the same location. When I wanted to be at $HOME, I could easily enter cd and be there.)
But I'm working on Mac OS and nearly every application made by Apple is scriptable with AppleScript, so is Terminal. I fetched one of the "Open Terminal Here" scripts to open a terminal from Finder. But I could not get behind the syntax. It looks great and is got to get, but difficult to write, when unfamiliar with it. But I could extract the right portions to open a Terminal at a given directory. But how do I fetch this one. Hmm.
The solution is pretty simple. Use a language, where I know how to fetch the current directory: Ruby. There is a great gem called rb-appscript. It's a Ruby-AppleScript bridge and does what I want. It's not easy to fetch the syntax here as well, but I just wanted to translate two lines, trial and error did the job.
... is a litte ruby script placed in '/usr/local/bin' called ot (Open Terminal) and it is not more but the following:
#!/usr/bin/env ruby -rubygems
require 'appscript'
include Appscript
term = app("Terminal")
term.activate
term.do_script(:with_command => "cd #{Dir.pwd}")
Now I can easily do what I want. If you are always using Terminal and calling the script only from one, you can even boil it down to three lines:
#!/usr/bin/env ruby -rubygems
require 'appscript'
Appscript::app("Terminal").do_script(:with_command => "cd #{Dir.pwd}")
The nicities of open source and open architectures. It was a pleasure.
1: Yes I call the "command key" "apple key", because everybody will instantly know what I mean. I'm not a fan of removing this icon from the keyboard.
I will try to cover Euruko 2007 at my kind of tumblelog at soup.schmidtwisser.de.
I just wanted to quickly share the slides from yesterday's monthly meeting.
The one on Camping:
You may find the code from the hacking session at our rubyforge svn, if you like.
And the other on LiterateMaruku:
Thanks again, for the nice evening.
I wanted to use camping to a literate programming style wiki with markaby syntax. Literally I wanted to make the followin possible:
Have a wiki page with the following content:
p "This page demonstrates Literate Markaby"
ruby_code do
a = 1 + 1
p "Output of a: #{a}"
end
And have the following output:
<p>This page demonstrates Literate Markaby</p>
<pre><code>a = 1 + 1
p "Output of a: #{a}"</code></pre>
<p>Output of a: 2</p>
Or it should look like this:
This page demonstrates Literate Markaby
a = 1 + 1
p "Output of a: #{a}"Output of a: 2
Markaby is Markup in Ruby. So the code entered as wiki markup will be eval'ed to get the output right. So when I would like to get the contents of the block passed to ruby_code I have to inspect live code. And there is one nice tool, that fits this task - ruby2ruby.
So all there is to do is to write a little camping helper, that implements the ruby_code method and generates the output.
STRIP_PROC = /^proc {\n(.*)\n}$/m
def ruby_code(&block)
self.pre do
self.code(block.to_ruby.gsub(STRIP_PROC, '\1'))
end
block.call
end
It is pretty easy, when you start in the middle. block.to_ruby gives you a string representation of the given block. Since it is a proc, ruby2ruby surrounds it accordingly. In this example the actual value would be
proc {
a = (1 + 1)
p("Output of a: #{a}")
}
The proc is okay, if we would like to execute the code once again, but in this case it is too much information. Therefore, the regular expression and gsub remove these characters. This string is then surrounded with html code and pre blocks, so it is marked up semantically.
I tested this code in a separte script with marbaky and ruby2ruby.
But then, a simple require 'ruby2ruby' in the targeted camping app, breaks it. Strange Markaby::InvalidXhtmlErrors are raised, where no exception was raised before. In fact, the occurred at the first call of tag! with attribute arguments. Since I was not able to track this down, I send my question to the camping-list and got the right hint.
ruby2ruby defines NilClass#method_missing to always return nil, instead of raising an exception. A nearby comment calls it an Object-C hack. I call it a bad idea. Other applications may rely on this basic behaviour, Camping does. Undefining it again, after the requiring ruby2ruby solved the strange errors. But on the other hand, ruby2ruby may rely on the changed behaviour. So this could not be it.
By accident I came up with a working solution. Unfortunately I don't know why I helped, but I guess a certain degree of meta-programming leads to this behaviour. Add a definition of tag! to your application and everthing is fine. This will look loke the following:
class MyApp::Mab
def tag!(*g,&b)
super
end
end
If you now think, why should I solve that again, You already did, you are right. You can get all the fixes and methods for free, now. To use the code, simply add an include LiterateMarkaby to your application's module. That's it.
Ahh, of course you need to copy the following lines as well..
require "ruby2ruby"
module LiterateMarkaby
STRIP_PROC = /^proc {\n(.*)\n}$/m
def self.included(base)
base.const_get(:Mab).class_eval do
def tag!(*g,&b)
super
end
end
base.const_get(:Helpers).class_eval do
def ruby_code(&block)
self.pre do
self.code(block.to_ruby.gsub(STRIP_PROC, '\1'))
end
block.call
end
end
end
end
As you can see: even more meta programming. The first reason: Helpers need to be defined directly within the applications helper module. Otherwise Markaby does not find them. And the other reason was already discussed, we need a Mab#tag! in our module.
There is only one thing better than meta-magic, even more meta-magic.
